昨天我們玩的東西比較單純。
把一大份文件丟給 Gemini，看看它能不能從大量文字裡找到我們真正想問的資訊。
測完之後，我們現在該考慮另一個問題：
如果資訊根本不是文字，而是一張圖呢？
畢竟我們在工作上並不是所有東西都會先寫成文件。
有時候是一張白板上的架構圖。
有時候是一張手繪流程圖。
有時候甚至只是幾個方框、幾條線，再加上一些只有自己看得懂的註記。
所以今天不寫程式。
我們來測試一件有趣的事情：
Gemini 到底看不看得懂工程師畫的架構圖？
這裡要先認識一個今天的關鍵字：
Multimodal，多模態。
簡單來說，就是 AI 不只處理文字，也可以把圖片、音訊、影片等不同形式的資訊一起拿來理解。
Google 官方目前的 Gemini 文件也將 Gemini 定位為原生多模態模型，可以直接接收圖片，進行圖片描述、分類與視覺問答等工作。
這代表我們以前可能會這樣跟 AI 工作：
我 ──文字──> Gemini
現在則可以變成：
┌── 文字
│
我 ──────┼── 圖片 ──> Gemini
│
└── 其他資訊
對工程師來說，這個差異其實滿重要的。
因為很多資訊原本就存在圖片裡。
這次我沒有特別做一張很漂亮的架構圖。
反而拿一張比較像工程師平常會畫出來的草圖。
例如：
如果這張圖是我自己畫的，我大概知道它在表達什麼。
但問題是：
Gemini 看得懂嗎？
把這張圖片直接放進 Google AI Studio，接著開始問。
第一個 Prompt 我故意寫得很簡單：
請分析這張系統架構圖。
請告訴我：
1. 圖中有哪些主要模組？
2. 每個模組可能負責什麼？
3. 模組之間的關係是什麼？
4. 請整理成一份簡單的技術說明。
結果最有趣的地方來了。
Gemini 不只是把圖片上的文字重新打一次，而是開始嘗試整理：
也就是說，它正在把：
「圖」→「結構」→「文字說明」
這條路走一遍。
這時候我們把之前學的 Prompt 技巧拿來用。
如果只問：
這張圖在做什麼？
得到的答案通常比較籠統。
所以我改成：
請分析這張手繪的系統架構圖。
請依照以下格式回答：
1. 列出所有主要模組
2. 說明每個模組可能負責的工作
3. 說明模組之間的資料流向
4. 整理成一份技術架構說明
5. 如果無法從圖片確認，請標示「推測」
這次的結果就明顯比較容易閱讀。
這也再次驗證了一件事情：
AI 能力很重要，但你怎麼問，同樣重要。
Google 的 Prompt 設計文件也建議，在多模態輸入情境下，要清楚說明不同資訊要如何使用，並明確定義希望模型輸出的格式。
既然 Gemini 能看架構圖，那我決定再多做一步。
在圖上故意留下矛盾：
A ─────> B
旁邊卻寫著：
資料由 B 傳回 A
然後直接問：
請檢查這張架構圖。
除了描述圖中的模組之外，
請找出可能存在的資料流向矛盾。
如果你無法確定，
請不要直接下結論。
這一次就不只是「看圖片」。
而是開始嘗試：
從圖中的資訊找關係，再判斷可能的問題。
這才是我覺得多模態能力真正有意思的地方。
這點我覺得非常重要。
今天的實驗很有趣，但不能因為 Gemini 能描述圖片，就直接把它當成人類工程師。
例如圖片模糊、箭頭太小、字寫得太醜，或者原本的設計意圖根本沒有畫在圖上，AI 都可能做出合理但錯誤的推測。
Google 官方文件也提醒，多模態模型雖然可以進行視覺問答與其他圖片理解工作，生成結果仍可能不準確，需要人工檢查。
AI 幫我讀圖，不代表 AI 幫我決定答案。
這個界線還是要自己守住。
看到這裡，我開始覺得 DevPulse 的想像又可以再多一點。
原本的 DevPulse 比較像：
程式碼
↓
Gemini
↓
找問題
↓
輸出結果
但如果加入今天的多模態能力之後，未來也可以變成：
程式碼 ─────┐
│
錯誤截圖 ────┼──> Gemini ──> 分析報告
│
架構圖 ──────┘
也就是說，AI 助理不一定只能「讀程式碼」。
它也可以開始理解工程師平常拿來溝通的其他資訊。
今天我們可以理解到
Gemini 不只是聊天機器人，它也開始具備「看東西」的能力。
和之前純文字的資料不同，今天再多放進一種資訊：
圖片。
所以目前的 DevPulse 已經可以從「幫我看程式碼」變成：
一個可以理解工程資訊的 Coding 助理。
至於下一步，就真的要開始寫程式了。
明天先來做第一週的小結，看看這幾天到底學到了什麼。
然後再正式跨進 API 的世界。
iThome鐵人賽
看影片追技術